[우테코]프론트엔드 프리코스 2주차 후기

미션을 진행하면서 느낀 점 🧑‍💻

• [우테코]프론트엔드 프리코스 2주차 레포지토리

두 번째 미션은 자동차 경주 게임을 구현하는 미션이었습니다. 지난 과제를 진행할 때 코드 컨벤션과 커밋 컨벤션을 계속 신경쓰면서 진행한 덕분인지 이번 미션을 진행할 때는 이번에는 코드 컨벤션과 커밋 컨벤션을 찾아보는 시간을 현저히 줄일 수 있었습니다. 그리고 그 시간만큼을 코드에 투자할 수 있어서 좋았습니다.

지난 과제에 대한 피드백 중 다음과 같은 내용이 있었습니다.

linter와 code formater의 기능을 활용해라.

그 동안 prettier를 사용해서 코드 포맷팅을 하는 기능은 정말 유용하게 사용하고 있었지만 eslint와 같은 린터를 사용해본 경험이 없었습니다. 지난 과제를 제출하고 미션을 진행하시는 다른 분들의 PR에서 eslint를 활용하시는 분들이 많은걸 보며 저도 한번 사용해봐야겠다고 생각했던 찰나에 피드백에도 해당 내용이 담겨 있어 eslint를 사용해보게 됐습니다.

eslint를 사용하면서 “아, eslint라는게 있는걸 알았음에도 나는 이걸 왜 이제서야 사용했을까”하는 생각이 들었습니다. 프로그래밍 요구사항에 있는 depth 제한, 함수의 길이 제한 같은 경우도 eslintrc옵션으로 간단하게 검사를 할 수 있었고 그 외에도 코드를 작성하면서 놓치기 쉬운 실수들을 eslint가 검사해 줌에 따라 실수를 미연에 방지할 수 있었습니다.

이번 미션은 저번 미션보다 프로그래밍 요구사항이 늘어나고 구현해야 할 부분도 많아졌습니다. 하지만 신기하게도 저번 과제를 진행하며 저 스스로의 안 좋은 습관들을 많이 개선한 덕분인지 오히려 지난 미션보다 코드를 작성하기 더 수월하다는 느낌을 받았습니다.

배운 점 👨‍🏫

• linter와 code formater를 활용하자

  • prettier가 자동으로 코드를 포매팅 해주는 덕분에 코드 포맷에 신경써야 할 부분이 많이 줄어들었습니다. 또한 포매팅 과정에서 문법에 맞지 않는 부분을 찾아주기도 하면서 작업 효율을 훨씬 높일 수 있엇습니다.
  • eslint 덕분에 과제 요구사항인 depth나 함수의 줄 제한 같은 눈으로 검사하기 까다로운 부분도 쉽게 잡아낼 수 있었습니다.
  • prettier와 eslint를 사용함으로서 사용하기 이전과 비교해 훨씬 생산성있게 코드를 작성할 수 있었습니다.
  • 각자의 툴을 따로 사용할 때도 정말 유용하겠지만 두가지를 함께 사용할 때 시너지가 배가 되는걸 경험했습니다.

• depth를 줄이자.

  • 지난 과제를 진행하면서 처음으로 depth를 제한한 채로 프로그래밍을 하게 됐습니다. 처음에는 다소 어렵고 까다로운 부분도 있었지만 depth를 제한하다보니 자연스럽게 함수들이 분리가 되고 함수들에게 더 작은 하나의 역할만 부여할 수 있게 됐습니다.
  • 그리고 이것은 곧 코드 가독성을 높이고 리팩토링을 수월하게 하는데 큰 도움이 됐습니다. 저번 과제를 진행하면서도 느꼈지만 정말 필요한 상황을 제외하고는 depth를 줄인채 프로그래밍 하는게 정말 좋다는 생각을 다시 한번 하게 됐습니다.

• method를 적극 활용하자

  • 저번 과제와 이번 과제를 진행하면서 평소에는 잘 활용하지 않던 많은 method들을 사용하게 됐습니다. forEach(), reduce(), every()등이 그 예입니다.
  • 관성적으로 for문이나 while문을 사용하던 부분들에서도 메소드를 활용하면서 depth를 줄일 수 있게 된건 물론 코드의 가독성도 높일 수 있었습니다.

아쉬운 점 🤦‍♂️

• 정하지 못한 네이밍 컨벤션

  • Google Javascript 코딩 컨벤션을 보면 다음과 같은 내용이 나옵니다.

    File names must be all lowercase and may include underscores (_) or dashes (-), but no additional punctuation. Follow the convention that your project uses. Filenames’ extension must be .js.

  • 파일 이름은 반드시 소문자여야 하며 _(언더바) 대신 -(대시)를 사용하라는 내용입니다. 즉 helloWorld.js같은 이름 대신 hello-world.js 같은 파일 이름을 사용하라는 내용입니다.

• export와 export default를 혼용해도 괜찮을까

  • 바로 위에 적은 내용과 이어지는 내용입니다.
  • 과제에서는 export default function(){}과 같은 형태로 기본 템플릿이 주어집니다.

  • 이어서 Google Javascript 코딩 컨벤션에 이런 내용 역시 나옵니다.

    Do not use default exports. Importing modules must give a name to these values, which can lead to inconsistencies in naming across modules.

  • export default를 사용하지 말고 export형태만 사용하라는 얘기입니다.
  • 여기서 저는 큰 고민에 빠집니다. 기본으로 주어지는 템플릿은 변경할 수 없는 상황에서 export default와 export를 혼용해서 사용하는게 맞을지, 아니면 전체 컨벤션을 통일하기 위해 전체 코드를 export default를 사용하는게 맞을지에 대한 고민입니다.
  • export default를 사용하는 경우 내보내는 함수와 파일 이름이 같아야 한다는 컨벤션이 있기 떄문에 위의 두 가지 구글 컨벤션을 지키지 못하게 됩니다.
  • export default를 전체 코드에 적용시키면서 일관성을 지키는게 맞을지 구글 코드 컨벤션을 따라야할지 많은 고민을 했습니다.
  • 긴 고민 끝에 기본으로 주어지는 export default템플릿을 전체 코드에서 사용하면서 일관성을 지키는 쪽을 택했습니다.
  • 이 부분은 지금도 고민하고 있는 부분이라 아쉬움이 남습니다.

• TEST

  • 더 좋은 코드를 작성하고 싶은 욕심에 클린 코드와 리팩터링 2판을 읽고 있습니다.
  • 두 책간 상충되는 부분도 존재하지만 두 책에서 모두 정말 중요하게 강조하는게 테스트 코드의 작성입니다.
  • 다른 분들의 PR을 보면 Jest 같은 툴을 이용해서 테스트를 진행 하신 분들도 계시고 직접 테스트코드를 작성해서 진행하신 분들도 볼 수 있었습니다.
  • 저 같은 경우는 console.log()를 통해서 제가 생각한 결과값이 올바르게 나오는지를 수시로 체크하면서 프로그래밍을 진행했는데 다음 번 과제에서는 테스트 코드를 통한 개발을 시도해보고 싶습니다.

앞으로 목표 🏃

• eslint더 잘 활용하기
• README에 구현할 기능 및 예외사항 꼼꼼하게 정리하기
• Test 코드 작성하기
• 네이밍에 더 신경쓰기